這邊開始講 Ray 跟 K8s 結合的好處跟應用情境，而在 kuberay 的架構下， ray 的架構除了有 head 跟 worker 的角色之外，另外還會需要一個 operator 的角色協助負責跟 k8s 溝通，所以 Head 會把 node requirement 透過 operator 要求增加資源或者減少資源。

如下圖所示，因為這複雜的架構，所以 Ray community 的部分已經把這三個角色包裝成 kuberay 的 helm package，可以直接使用就可以直接把 Operator 跟 Head 還有 Work 三個角色都 deploy 到 k8s cluster 上面了

Refer: ray.io

KubeRay Operator

Operator 的角色就像是一個負則管理 resource 的角色，因為他會跟 k8s 要求新增或減少 resource ，而同時也記錄著哪些資源是放置 Ray task 的，所以這個在 k8s 的架構下，可以充分的協助新增或減少支援，如果對 k8s 比較熟的話，大致上可以想像一下就是負責下 kubernetes API 的部分，透過 API 來跟 kubenetes 來調用資源的一個角色

Ray Autoscaler

這部分還是要講一下，因為Ray Ecosystem 裏面，其實每個 Ray 都是視為獨立的 pod ，所以每一個Pod 都可以下參數要求 CPU, GPU and Memory 的數量，因此就會有資源不夠需要增加或減少 Ray Node 的狀況，所以 AutoScaler 就是要負責協調Ray Node 要增加或減少的狀況。

Ray Head Node Pod

前面之前已經講過了就是 Ray Head 的角色，Pod 是因為基本上他們都是以 Pod 的方式生存在 ，而每個Head Node 都算是一個獨立的 Ray Cluster，這個的在 Kuberay 裡面主要的責任除了調配 Ray Pod 到不同的 Worker Node 之外，另外就是跟 KubeOperator 去要新的 Node ，然後新的 Node 設定為 ray worker ，所以建立完之後就可以把 Raypod 移過去 worker Node 上面工作。

Ray Worker Node Pod

一堆 pod 來跟隨著 Head Node 的調度，這邊就不用多說，主要就是在處理的東西

以上就是 Kubernetes 上面建立 Kuberay 的好處，再搭上 aws 上面的ec2 或者 eks 的話，就可以很輕易的去擴增 Ray Worker Node

Note : 這邊講到 Kuberay 的部分，其實在前幾個月在 aws blog 的部分有找到一篇 aws sa 發的 kuberay 如何部署在 aws 上面，這篇也可以參考他的 Example 也許會有幫助

Reference

1. https://aws.amazon.com/cn/blogs/china/improving-quantitative-strategy-research-efficiency-with-amazon-eks-and-ray/
2. https://docs.ray.io/en/latest/cluster/kubernetes/index.html